home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19981211-19990422
/
000165_news@watsun.cc.columbia.edu _Fri Jan 29 12:18:43 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-04-21
|
7KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA13893
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 29 Jan 1999 12:18:43 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA12968
for kermit.misc@watsun.cc.columbia.edu; Fri, 29 Jan 1999 12:08:20 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Subject: Re: Transparent printing
Date: 29 Jan 1999 17:08:18 GMT
Organization: Columbia University
Message-ID: <78spu2$cl5$1@newsmaster.cc.columbia.edu>
To: kermit.misc@mailrelay2.cc.columbia.edu
In article <Gqks2.225$VQ5.2885478@news1.i1.net>,
Scott Nelson <sbnelson@i1.net> wrote:
: I developed a utility similar to FSF's screen program so that our K95
: users connecting over the internet can re-connect to their "session" if
: they get bumped off (phone line or internet problems). (It ended up
: being easy to add "shadowing" features so that our customer support team
: can connect and help someone).
:
: application ---- utility ----- user
:
: The link between the utility and the user can be broken and
: reestablished without the application even knowing about it. Pretty
: snazzy isn't it :-). It allows us to use our legacy application over
: the internet, using kermit with encryption and authentication. The
: application displays its data even if there is no connection on the
: other end. When the user re-connects, the utility sends a "refresh the
: screen" function key to the application and bingo - they are back where
: they need to be. The reason I don't block data when the user
: disconnects is that I don't know exactly when the user gets
: disconnected. Sometimes, it's not until they login again. That's why I
: let the data pass freely when disconnected and then have a simple
: "refresh" fkey.
There is a commerical package called FacetTerm from Structured
Software Solutions that does something similar. FacetTerm supports
multiple sessions that the user can switch between. The way it works
is that the "utility" would actually store the active screen contents
(in other words it has a built in emulator for each terminal type) so
that when the "user" re-connects or switches sessions the screen can
be restored to the appropriate state without interfering with the
application (not all applications will handle a refresh screen
properly.)
I think that by not blocking the application when the user
is deconnected that you leave yourself open to a series of potential
problems depending on the state the terminal was in. Your method
assumes that the terminal is always in the default state. What happens
if the character-set tables are initialized by the host, margins are
adjusted, wrap flags, keys are refdefined, colors set, or any of the
hundreds of other bits of state information that would need to be
restored when either a connection is restored or the support group wants
to join a session mid-stream?
: My problem is printing.
:
: 1) You loose printer output when disconnected; user must request report
: again (and hopefully they stay online longer)
: 2) Long reports to the screen makes it impossible to use the screen.
: 3) We can't share the printer. (The data is sent directly by the
: application; not by a spooler)
:
: What I would like to do is this: Have my utility read two pseudo ttys
: instead of one; one from the application and one from the spooler. It
: would then multiplex this output to the user. I could give the
: application priority over the spooler. I guess I would also need to
: interpret the application's output to prevent breaking up an escape
: sequence.
:
: Any ideas on how I should do this? Originally I thought that I was
: going to use only K95 in scoansi mode and could use a formula to
: determine when an escape sequence ends, but now I have learned that I
: need to support all terminals connected directly to the system (They
: loved the customer support shadowing idea).
:
: Moreever, I don't have ANY solution to #1 above.
Your first problem is that the application sends the printer output
to the terminal using transparent print sequences. If you can't change
the application to print to a spooler the only way you are going to be
able to affect the method of printing is for your "utiltiy" to recognize
the transparent print sequence and strip the print job and send it to
a spooler or something else.
So now you have the print job in a spooler. But you still want the
user's terminal emulator to get the output. You can continue to send
the spool data to the terminal using transparent print sequences but
now you have introduced a new problem. Since you are breaking a
single job up into multiple pieces, how does the terminal emulator now
when one job has finished and a second job has begun? The only way
to be sure that a terminal will print a job in one piece is to send it
as one piece.
If you are thinking about using a new method for multiplexing the
print data over the connection then you are going to have to make
sure that all of the terminals that you are using can support it.
(Probably not feasible without replacing all existing terminals
and emulation software with something new.)
Of course, if you are using TCP/IP connections you could setup
LPDs on each of the clients to accept the print job from the
spooler, but that would also mean bypassing the authentication
and encryption you received via the Telnet session.
As for knowing when an escape sequence is complete. This is
fairly easy to do with SCOANSI and any other terminal based on
ANSI X3.64, ISO 6429, or HP Term0 since these terminal types use
highly structured state machines. Any of the so called ASCII terminals
such as Wyse, Televideo, ADDS, Data General, QNX, VT52, etc. will
require that your "utility" implement a complete terminal emulation
for each model because there is no predicatable way of knowing the
length of a particular escape sequence.
I don't want to discourage you but what started off as a neat utility
has suddenly become very complicated.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org